-
Notifications
You must be signed in to change notification settings - Fork 823
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove rendering of residential, unclassified, cycleway, path, track highway areas #4096
Conversation
project.mml
Outdated
('railway_' || (CASE WHEN (railway IN ('platform') | ||
AND (tags->'location' NOT IN ('underground') OR (tags->'location') IS NULL) | ||
AND (tunnel NOT IN ('yes', 'building_passage') OR tunnel IS NULL) | ||
AND (covered NOT IN ('yes') OR covered IS NULL)) | ||
THEN railway END)) | ||
) AS feature | ||
FROM planet_osm_polygon | ||
WHERE highway IN ('residential', 'unclassified', 'pedestrian', 'service', 'footway', 'track', 'path', 'platform') | ||
WHERE highway IN ('pedestrian', 'service', 'footway', 'cycleway', 'track', 'path', 'platform') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see this adds back highway=cycleway, which is currently missing from this selection.
Do we actually want to render highway=cycleway areas?
Are there really areas where bicycles may travel freely in any direction?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't given it much thought either way. The WHERE clauses were the only places missing cycleway, we were attempting to render it in the MSS and the COALESCE
#1967 requests removing footway, cycleway, track, and path so I'm going to add those |
These are also mainly inappropriately used where area:highway could be used instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, this will remove several confusing renderings. Test images in Latvia show that most current examples of these features are mistakes, eg roundabouts or turning circles mapped as area=yes or highway=footway areas that should be mapped as highway=pedestrian areas instead, and the current rendering for highway=track and highway=residential/unclassified is confusing.
highway=track area+yes current
highway=unclassified + area=yes before
- A building is currently hidden by the rendering.
What is wrong with area=yes on a footway (unless of course it is abused for the width of a linear feature)? It is very popular for minor areas of omnidirectional foot traffic, such as the round area in the middle of a park where all footways meet and you have some benches around. This is too insignificant for me to be a "highway=pedestrian". What is the logic to render area=yes on pedestrian but not on footway? The example above with the hidden house is a tagging error, it should have been cut out as a MP. Do we start dropping all rendering where a tagging mistake has been found? |
I added another example in: |
While many examples are misused in such a way, it appears that majority of features with this tag are small pedestrian areas. The problem with the current rendering is that it works well with highway=pedestrian, since the fill and casing colors are the same, but it doesn't look anything like footways or cycleways. |
A solution would be to unify the appearance of linear highway=footway and =pedestrian, in the current pedestrian style (grey) just with different width (footway a bit narrower). That would also reduce the noise from the red footways. IIRC there were attempt to do something like that here in the past, e.g. here: |
As for highway=track areas, they are certainly rendered too prominently, a good approach would to adapt them more to the track appearance, e.g. making them darker and/or use some hatching or pattern. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The following data on the different highway types - and highway=pedestrian for comparison:
type | count | area=yes + relations | wiki documenting use on polygons |
---|---|---|---|
unclassified | 13M | 4166 + 197 | no |
residential | 51M | 20704 + 1305 | no |
track | 18M | 5612 + 277 | no |
path | 8M | 1950 + 265 | no |
footway | 12M | 53371 + 6979 | yes |
pedestrian | 570k | 160959 + 22536 | yes |
Based on that for unclassified, residential, track and path i'd say removing rendering due to a lack of broad use and acceptance by mappers is in order. For highway=footway i'd say more that this seems to be a synonym for highway=pedestrian when used on polygons - i can see no systematic difference between those in use or documentation - and as such it would be good to remove it - despite there being some use. But that is not a very strong opinion on my side - after all such use is nearly 1/3 of that of highway=pedestrian and you could argue that it is a well established synonym.
Have not tested the code but @jeisenbe seems to have done that.
I disagree strongly. First, this is yet another example of the current practice, that after discussing a certain change in rendering for one feature, another feature is included in this change on the last minute, without being sufficiently discussed. In this case, the proposed change is not even present in the title of this PR, it is kind of a stealth removal. Second, the PR now removes a feature used 55 k + 7k = 62k times, documented in the wiki and not declared as deprecated. The removal will cause pointless mechanical changing such areas to highway=pedestrian, which they often aren't. While @imagico sees them as synonyms, I see a difference. There are plenty other examples that are tagged differently but rendered identical. OSM is a database that is not just driving this style. It has other applications where this distinction is significant. |
Clearing up a few misconceptions:
|
To clarify: I am happy with merging this PR as-is, because the However, if @pnorman decides to keep the current rendering of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just noticed that this will need to remove label drawing for these in roads-area-text-name
as well - otherwise this is confusing.
This keeps the layer consistent with the changes to the fills.
Additional changes were added to the PR in response to comments from a review.
I've now edited the title to reflect the changes.
I don't consider the wiki status as important as the actual usage numbers.
I'm not sure, based on the table I see use. Not as much as pedestrian, obviously, but more than the other roads in the table. |
@pnorman - do you mean you are not sure about highway=footway areas? I t's true that area tagging of those features is more common that the others on the list: about 1 out of 200 footway features are currently mapped as areas, while for the others on the list there are less than 1 per 1000. Like I've said, I support removing the rendering of residential, unclassified, track and cycleway area renderings, but I can go either way about highway=footway - it's odd to render it the same as highway=pedestrian, but we could work on fixing that later, if necessary. |
I've checked the local data in Oregon, and I noticed that the great majority of highway=footway + area=yes closed ways also have a man_made=pier or public_transport=platform feature: http://overpass-turbo.eu/s/Sob - 44 total features Overall, a smaller percentage of In the case of platform, the correct tag is highway=platform for the bus platforms which were mapped in Oregon (or sometimes railway=platform in other contexts): https://www.openstreetmap.org/#map=19/44.04760/-123.07723 For the piers, the tagging is not exactly wrong, but it's not commonly added by mappers who are not using iD: Here are the other 5 features in the State: https://www.openstreetmap.org/#map=19/45.50853/-122.67222 |
Requested change in roads-area-text-name has been made
Man made piers + highway=pedestrian: https://www.openstreetmap.org/#map=18/44.80906/-124.05909 https://www.openstreetmap.org/#map=19/44.98982/-123.99457 |
@pnorman - I'm waiting for you to merge this PR as-is or make changes if you want. Do you plan to merge it soon, including removing the rendering of highway=footway areas, or change it to keep the rendering of highway=footway for now? |
I'll change it |
@@ -1758,7 +1758,7 @@ Layer: | |||
name | |||
FROM planet_osm_polygon | |||
WHERE way && !bbox! | |||
AND (highway IN ('residential', 'unclassified', 'pedestrian', 'service', 'footway', 'cycleway', 'living_street', 'track', 'path', 'platform') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'footway' is missing here
If I understand correctly, area/footway is being kept for now. Could this please been reflected in the title? It seems that the message to osm-talk still included the removal, probably by copy/pasting? |
Sorry, that should not have been in the list of changes for v5.1.0. I've updated the title of this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, looks ready to merge
footway still in the title? |
Title updated, thank you for catching that. |
Fixes #3995
Fixes #1967
Removes the rendering of highway=residential area=yes and highway=unclassified area=yes polygons. In #3995 these were established to commonly be a tagging mistake.